Databases which respond to queries are widely used. In such databases, a client—such as a client application—submits a query to the database, and the database provides a query response in reply.
In many databases, database sessions are used to manage database communication resources, which are limited. A database session is, in effect, a communication line between a database and a user. In such databases, a query is submitted to the database using a database session. Hence, when a client of the database wishes to query the database, it is necessary to procure the use of a database session through which to process the query. Conversely, if a database session cannot be obtained, it is not possible to query the database. Where a relatively large number of clients wish to query the database, it becomes preferable to have a system for managing the allocation of database sessions.
The term “database session” is, for the purpose of this specification, meant to be synonymous with the term “application session”. In some databases, the term “application session” is used by way of preference, and exemplifies the fact that the application gains control of and uses the session.
One existing system for managing database sessions is commonly known as connection pooling. In connection pooling, a server maintains a pool of available database sessions, although these are not an unlimited resource, and the pool is subject to becoming empty. A client application wishing to query the database makes a request for a database session. In response—and where possible—the server allocates a database session to the client from the pool of available database sessions. Effectively, the server lets the client “borrow” one of the sessions. Once the client is allocated a session, the client gains control of the session. That is, the client may use—or not use—the session as desired. When the client decides that it has finished with the session, it should take the active step of returning the session to the server. If the client does not return the session to the server, the session remains inactive and unavailable until such a time as the server recognises and reclaims the inactive session. As such, there are time periods during which the client does not necessarily use the session—that is, provide queries to the database—although the client has control of the session. In particular, the session is idle when no queries are being submitted. Effectively, the allocated resource is reserved for use, but not actually used.
In connection pooling, a single session is required for each client that wishes to query the database. That is, if there were 50 clients that wished to query the database over a predetermined period, it would be necessary to supply 50 sessions during that period. A problem arises given that sessions are a finite resource—the pool is inherently limited and subject to becoming emptied. When the number of clients wishing to query the database exceeds the number sessions available, one or more clients will not be able to borrow a session, and as such will not be able to query the database. These clients must wait until other clients return sessions.
It will be appreciated that, where connection pooling is used, the database will not always be available for querying by all clients. It will further be appreciated that users are prevented from querying the database even where the database is being queried well within the operational limitations of that database.
Any discussion of the prior art throughout the specification should in no way be considered as an admission that such prior art is widely known or forms part of common general knowledge in the field.